A file server is a computer that provides file service relating to the organization of information on storage devices, such as disks. The file server or filer includes a storage operating system that implements a file system to logically organize the information as a hierarchical structure of directories and files on the disks. Each “on-disk” file may be implemented as a set of data structures, e.g., disk blocks, configured to store information. A directory, on the other hand, may be implemented as a specially formatted file in which information about other files and directories are stored.
A filer may be further configured to operate according to a client/server model of information delivery to thereby allow many clients to access files stored on a server, e.g., the filer. In this model, the client may comprise an application, such as a database application, executing on a computer that “connects” to the filer over a computer network, such as a point-to-point link, shared local area network (LAN), wide area network (WAN), or virtual private network (VPN) implemented over a public network such as the Internet. Each client may request the services of the file system on the filer by issuing file system protocol messages (in the form of packets) to the filer over the network.
A common type of file system is a “write in-place” file system, an example of which is the conventional Berkeley fast file system. In a write in-place file system, the locations of the data structures, such as inodes and data blocks, on disk are typically fixed. An inode is a data structure used to store information, such as meta-data, about a file, whereas the data blocks are structures used to store the actual data for the file. The information contained in an inode may include, e.g., ownership of the file, access permission for the file, size of the file, file type and references to locations on disk of the data blocks for the file. The references to the locations of the file data are provided by pointers, which may further reference indirect blocks that, in turn, reference the data blocks, depending upon the quantity of data in the file. Changes to the inodes and data blocks are made “in-place” in accordance with the write in-place file system. If an update to a file extends the quantity of data for the file, an additional data block is allocated and the appropriate inode is updated to reference that data block.
Another type of file system is a write-anywhere file system that does not over-write data on disks. If a data block on disk is retrieved (read) from disk into memory and “dirtied” with new data, the data block is stored (written) to a new location on disk to thereby optimize write performance. A write-anywhere file system may initially assume an optimal layout such that the data is substantially contiguously arranged on disks. The optimal disk layout results in efficient access operations, particularly for sequential read operations, directed to the disks. A particular example of a write-anywhere file system that is configured to operate on a filer is the Write Anywhere File Layout (WAFL™) file system available from Network Appliance, Inc. of Sunnyvale, Calif. The WAFL file system is implemented within a microkernel as part of the overall protocol stack of the filer and associated disk storage. This microkernel is supplied as part of Network Appliance's Data ONTAP™ software, residing on the filer, that processes file-service requests from network-attached clients.
As used herein, the term “storage operating system” generally refers to the computer-executable code operable on a storage system that implements file system semantics and manages data access. In this sense, ONTAP software is an example of such a storage operating system implemented as a microkernel. The storage operating system can also be implemented as an application program operating over a general-purpose operating system, such as UNIX® or Windows NT®, or as a general-purpose operating system with configurable functionality, which is configured for storage applications as described herein.
Disk storage is typically implemented as one or more storage “volumes” that comprise physical storage disks, defining an overall logical arrangement of storage space. Currently available filer implementations can serve a large number of discrete volumes (150 or more, for example). Each volume is associated with its own file system and, for purposes hereof, volume and file system shall generally be used synonymously. The disks within a volume are typically organized as one or more groups of Redundant Array of Independent (or Inexpensive) Disks (RAID). RAID implementations enhance the reliability/integrity of data storage through the redundant writing of data “stripes” across a given number of physical disks in the RAID group, and the appropriate caching of parity information with respect to the striped data. In the example of a WAFL file system, a RAID 4 implementation is advantageously employed. This implementation specifically entails the striping of data across a group of disks, and separate parity caching within a selected disk of the RAID group. As described herein, a volume typically comprises at least one data disk and one associated parity disk (or possibly data/parity) partitions in a single disk) arranged according to a RAID 4, or equivalent high-reliability, implementation.
Within a known storage system, the storage operating system is loaded from a kernel image that resides in compressed form at a location on the interconnected disk array. The compressed kernel image is located on the disk array by a finder algorithm, and loaded at an appropriate location in memory. It is then extracted into an operative kernel based upon a decompression algorithm, and placed in a predetermined address space in the file server's memory.
Briefly, the kernel image is loaded initially at boot-up of the file server in response to a series of commands executed by firmware (FW) that resides on the file server's system circuit board (mother board), in communication with other file server components. The firmware includes a set of basic operating instructions stored on a programmable read-only memory (an EPROM), such as a Flash memory—performing a function analogous to a basic input/output system (BIOS) in a personal computer. That is, the firmware is the first command instruction set to be accessed by the file server's processor (after internal instructions) when power-on is applied. These instructions allow disk access and other basic functions that enable loading of the complete operating system from the disk array (or other fixed storage location).
The full “reboot” of a file server involves, in essence, the complete shutdown and clearance of the processor and memory from a booted-up state, and (often) a recycling of system power. After shutdown, the entire system is reinitialized and the memory is reloaded with all necessary software and operating system components. A reboot sequence may be undertaken for a variety of reasons. Reboot may be required due to power-failure or hardware failure. A system error, unexpected internal software state, software bug and/or kernel “panic” condition may necessitate a reboot (in order to correct these conditions). The addition of new hardware, adapters or drivers may also necessitate reboot—particularly the attachment of new disk units to the attached disk array. Various hardware and software checks and maintenance procedures may also entail a reboot sequence.
A file server typically performs the following operations (among others) during a traditional reboot sequence:
As shutdown occurs, all applications are closed, consistency points and other closing data handling/file service activities are completed (as applicable) and connections with clients are brought down. The file server memory is then cleared by a “handoff” to the firmware, based upon a call for a “reboot” by the storage operating system. This clears the final memory locations, and handles the final shutdown of processor and memory functions.
Once boot-up subsequently begins, a series of steps generally occur. The firmware instructs an initial full file server memory test, scanning the memory for errors and clearing any built-in Error Correction Circuitry (ECC) bits (if applicable). This test may last thirty seconds or more on a large-memory (one-gigabyte and greater) file server. Other conventional power-on self-tests (POSTs) are also implicated at this stage. The useable file server memory is zeroed by the firmware, and various hardware chips may undergo power-up tests, such as the LCD display chip and the serial input/output (SIO) chip(s). The firmware now also locates the data-compressed image of the storage operating system kernel stored on disk, and loads the compressed image into an appropriate memory address space. The locating and reading of the kernel from disk into memory may consume approximately ten seconds on a fast-running file server. Once the kernel is loaded, various hardware connections are established and checked, and tests of attached hardware may be performed (PCI/bus-based devices, for example).
A full or “cold” boot process as a result of a reboot command, therefore, consumes significant file server time and resources. Clearly, the more quickly a reboot is accomplished, the less time clients awaiting file service must wait for that service to resume. Because reboot time is downtime from the perspective of clients, saving even a few seconds during reboot can significantly affect overall system availability—particularly where many attached clients exist and a multiplicity of reboots may be required throughout an operating year. In fact, to attain 99.999% system reliability (the desired “Five Nines”), downtime must be limited to only about five minutes per year.
It is recognized that certain boot-up processes may be avoided in many circumstances, as the risk of malfunction or failure of the subject hardware and software affected by these processes is low in such instances. In other words, where a reboot is undertaken simply to (for example) add a new disk drive or license a new module in the storage operating system, it is not usually expected that there are faults with any hardware or software components. As such, tests on unaffected components and software may (for all practical purposes) safely be skipped. Other time-consuming tasks may also be skipped under certain circumstances.
It is therefore an object of this invention to provide a system and method for faster reboot of a file server than a conventional “cold” reboot that does not appreciably increase the risk of propagation of a software or hardware error/failure. This system and method should generally reduce downtime as a result of file server unavailability.